System and method for managing computing resources

ABSTRACT

Disclosed herein is a commodity infrastructure operating system that manages and implements the resources and services found in the heterogeneous components of the common infrastructure using a fabric manager. A fabric manager managing computing resources in one or more platforms and one or more partitions residing on the platform by monitoring each platform and partitions, and issuing instructions to a hypervisor or other management agent on a platform to execute one or more platform management commands, such as commission a new partition onto a platform.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of co-pending U.S. patentapplication Ser. No. 14/108,521, filed on Dec. 17, 2013, and also claimspriority to U.S. Provisional Patent Application Ser. No. 61/738,161,filed on Dec. 17, 2012, all of which are incorporated by reference intheir entirety.

FIELD OF THE DISCLOSURE

The subject matter disclosed herein relates generally to resourcemanagement in a commodity computing environment.

BACKGROUND

Computing systems sharing various infrastructure and software componentshave many desirable attributes; however, one of the challenges of usingthem is to support applications, often mission-critical applications,while taking advantage of low cost “commodity” infrastructure. Suchenvironments can be thought of as “commodity-based” infrastructures inwhich heterogeneous computing components are amalgamated into a commoncomputing system.

Such computing environments may result in a heterogeneous collective ofcommodity components, each needing access to applications, data,hardware resources, and/or other computing resources, across thecomputing system. Often, operating such environments requires developersto possess and/or utilize a variety of commodity skills and tools.

What is needed is a computing system in which applications are easy tocreate and/or execute, without losing the advantages of either thecommon infrastructure paradigm or the individual commodity componentsinhabiting the common infrastructure. What is needed is way to keepfeatures of common infrastructure computing while enabling commodityskills and tools to effectively operate applications of many types, withfocus in some cases on mission critical applications. What is needed isan automated manner in which an application that spans heterogeneouscomputing components can be commissioned as a single object, as opposedto manually commissioning the individual services and computingcomponents.

Traditional integrated operating systems include all service componentsfor a computing system into an application execution environment, fileand storage management service, database management service, messagingservice, and so on. Such, integrated operating systems execute on eithera dedicated physical platform or on a virtualized platform managed by ahypervisor.

Depending on the operating system deployed onto a platform, theservices, and the manner in which they execute, may vary. Management ofthe an integrated operating system is often accomplished by managementtools also integrated into the operating system itself. In well-knownnetworking environments, there may be a variety of integrated operatingsystems deployed, thereby resulting in a “heterogeneous” environment.

What is needed is a way to pool, manage, control, and/or allocate, thevarying services of the disparate operating systems in a heterogeneousenvironment.

Storing data on a computing device, in a reusable format, is well-knownin the art. Once stored, adding and updating data is now commonly usedin transaction processing by online transaction processing (“OLTP”)technologies. As transaction processing demands rise, emphasis isshifting from data storage and retrieval to implementing tools forbusiness analytics.

What is needed is a common infrastructure capable of storing,distributing, and retrieving data, while also efficiently operatingwithin a common infrastructure's heterogeneous and potentiallygeographically-dispersed environments, to perform data analytics. Whatis also needed is a way for data to be stored according to variousdatabase models.

In known enterprise systems or transactional applications, utilizing avariety different database models, e.g., network or hierarchical, thehigher-level applications must organize the underlying data so that thedata complies with the various database models.

What is needed is a way for applications and/or databases to storeand/or utilize data, regardless of database models, without altering theapplications, databases, and/or data.

Transactional applications may be built on a variety of models, e.g.,functioning on programming that is stored a database with a networkmodel, but storing and retrieving data in database with a relationalmodel. Data is often copied, or replicated, between these databases toensure the data is in the right model.

What is needed is way to mitigate or eliminate the need to extract,transform, and/or load data between databases. What is needed is a wayfor devices to view and/or interact with “live” data without the needfor copies.

SUMMARY

Disclosed herein is an commodity infrastructure operating system thatmanages and implements the resources and services found in theheterogeneous components of the common infrastructure.

In one embodiment, a computer-implemented method for managing computingresources comprising: determining, by a computer, a target platform toreceive a new partition image; determining, by the computer, whether thetarget platform comprises a hypervisor having a management agent formanaging a platform; installing, by the computer, a management agentwhen the target platform does not comprise a hypervisor; andinstructing, by the computer, the management agent to commission the newpartition image on the target platform.

In another embodiment, a computer-implemented method for managingcomputing partitions: receiving, by a computer, a status signal from amanagement agent stored on a platform, wherein the status signal is asignal comprising a platform status associated with the platform and oneor more partition statuses associated with one or more partitionsresiding on the platform; determining, by the computer, whether theplatform stores a partition blueprint based on the platform status;determining, by the computer, whether a partition executes a standardimage based on a partition status associated with the partition;commissioning, by the computer, the partition blueprint when theplatform does not comprise the partition blueprint, wherein themanagement agent is instructed to instantiate the partition blueprint onthe platform; and commissioning, by the computer, the standard imagewhen the partition does not comprise the standard image, wherein themanagement agent is instructed to install the standard image.

In another embodiment, a computer-implemented method for monitoringevents comprising: receiving, by a computer, an event from a managementagent stored on a platform; logging, by the computer, the event in anevent log; determining, by the computer, whether the event is a generalevent or a call home event based on one or more event-type criteria;notifying, by the computer, an administrator when the event is a callhome event; and notifying, by the computer, the administrator when theevent is a subscribed event, wherein a subscribed event is a generalevent to which the administrator subscribes for notifications.

Additional features and advantages of an embodiment will be set forth inthe description which follows, and in part will be apparent from thedescription. The objectives and other advantages of the invention willbe realized and attained by the structure particularly pointed out inthe exemplary embodiments in the written description and claims hereofas well as the appended drawings.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory and areintended to provide further explanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure can be better understood by referring to thefollowing figures. The components in the figures are not necessarily toscale, emphasis instead being placed upon illustrating the principles ofthe disclosure. In the figures, reference numerals designatecorresponding parts throughout the different views.

FIG. 1 illustrates a schematic representation of a commoninfrastructure.

FIG. 1A illustrates fault trees relating to each application in anexemplary embodiment.

FIG. 2 illustrates a prior art application execution environment withexamples of services available in an integrated operating system stack.

FIG. 3 illustrates a fabric operating system approach to providingservices to an application in an exemplary embodiment of the commoninfrastructure.

FIG. 4 illustrates the various blueprints that may be commissioned intopartitions of the common infrastructure.

FIG. 5 illustrates the features and process of commissioning operatingsystems, thereby commissioning into the infrastructure one or moreservices that reside on the blueprints.

FIG. 6 illustrates an embodiment of the interconnect fabric and thevarious aspects.

FIG. 7 illustrates a common infrastructure architecture showing varioustypes of managers in a datacenter and their management domains.

FIG. 8A illustrates a prior art data storage paradigm where dataconforms to expected structural requirements of a database.

FIG. 8B, illustrates one embodiment of a data foundation common datastore.

DETAILED DESCRIPTION

The present disclosure is here described in detail with reference toembodiments illustrated in the drawings, which form a part here. Otherembodiments may be used and/or other changes may be made withoutdeparting from the spirit or scope of the present disclosure. Theillustrative embodiments described in the detailed description are notmeant to be limiting of the subject matter presented here.

Reference will now be made to the exemplary embodiments illustrated inthe drawings, and specific language will be used here to describe thesame. It will nevertheless be understood that no limitation of the scopeof the invention is thereby intended. Alterations and furthermodifications of the inventive features illustrated here, and additionalapplications of the principles of the inventions as illustrated here,which would occur to one skilled in the relevant art and havingpossession of this disclosure, are to be considered within the scope ofthe invention.

Fabric Computing Architecture

In some embodiments, the components may be formed into logical groupsthat allow the common infrastructure to implement the sum of thecomponents in a concerted manner. For example, a hardware group maysupport high-availability or disaster-recovery configurations forinfrastructure resources through redundancy and/or load-balancing. Asanother example, software groups comprising one or more “images” may bespecified to seamlessly operate in concert as a single applicationthough several images are operating at once.

Embodiments of a common infrastructure comprise all platforms, servicepartitions, and an interconnect or interconnect fabric that facilitatescommunication between one or more partition images residing on each ofthe platforms. The common infrastructure comprises a suite of hardware,software, and services (together “components”), which may generateand/or support partitioned computing environments. These partitions maybe linked together through the fabric-based infrastructure using theinterconnect.

A partition can be a set of one or more computing resources of aphysical platform that are capable of supporting, isolating, andcontaining, on the platform an operating system image, middleware,and/or one or more applications. The partition residing on a platform isgenerated, and in some embodiments, managed, by a hypervisor component.In other words, a partition may be a set of physical platform resourcesallocated by the platform's hypervisor instance to isolate and contain adiscrete execution environment within the partition being created. Insome embodiments, the hypervisor allocates resources to a partition suchthat the hypervisor prohibits those allocated resources from beingshared with other partitions that may also reside on the platform. Inother embodiments, the hypervisor may be capable of dual-assigning asubset of the platform's resources to more than one partition residingon the platform. Further embodiments capable of dual-assignments ofplatform resources across more than partition may be capable ofautomatically detecting a dual-assignment need.

An operating system image may be the operating system, middleware,business logic, and/or applications, which execute within a partitionand capable of being persisted in some non-transitory machine-readablestorage.

Embodiments of a common infrastructure may comprise one or moreplatforms. Each platform is a computing device comprising a hypervisor.A platform is often a server computer. But, depending upon theembodiment, a platform may be a physical server, a personal computer, orother physical computing hardware capable of meeting the computingrequirements of a platform in accordance with the invention. A physicalserver may be a computing device, or other hardware, capable of hostingmultiple operating system images.

A hypervisor may be a hardware component, and/or a software component,of the fabric that resides on a platform. A hypervisor may be capable ofpartitioning the computing resources of the platform into one or morepartitions.

In some embodiments, the hypervisor is also capable of managing thecomputing resources residing on a platform. Depending upon theembodiment, each platform in the infrastructure hosts zero or onehypervisor partitioned instances. An instance can be a collection ofinterdependent guest partitions and/or service partitions. A servicepartition can be a partition image intended for infrastructureadministration. In some embodiments, service partitions are administeredby the infrastructure administration and behave as virtual machines. Aguest partition being a partition image where applications, and in somecases the environment of the partition as a whole, may be managed by thecustomer.

Embodiments of such a fabric architecture may implement variousapplications in virtualized computing environments. Some embodiments mayconsolidate one or more applications, or application parts, onto asingle platform. Other embodiments may consolidate one or moreapplications, or application parts, into a single common infrastructure.In embodiments implementing partitioning capabilities, the partitioningcapabilities may isolate one or more virtual environments from oneanother without regard to the physical servers housing the virtualenvironments.

The common infrastructure, sometimes referred to as fabric computing maybe a collection of one or more component nodes and, in some cases,non-component nodes. Component nodes are those nodes storing and/orexecuting infrastructure management tools. Each of the software toolsand each of the physical structures are each components of theinfrastructure.

FIG. 1 illustrates a schematic representation of a commoninfrastructure.

A common infrastructure 100 may comprise one or more platforms P_(fm1),P_(fm2), P_(fm3), P_(fm4) that are partitioned by hypervisor instancesinto one or more partitions: a service partition SP_(x), a set ofpartitions P_(1j) that each host an operating system image executing afirst enterprise application (“App1”) 106, and a set of partitionsP_(2j) that each host an operating system image executing a secondenterprise application (“App2”) 107.

An interconnect fabric 103 may be associated with one or more platformsP_(fm2). An interconnect fabric 103 may contain one or moreinfrastructure connections, or endpoints 110, 111. An endpoint 110, 111may be a service, application, and/or other computing resource within apartition that that uses a connection to facilitate communicationbetween partitions P_(1j), P_(2j). For example, a first partition P₁₁utilizes an endpoint 110 service to communicate with an endpoint 110service of a second partition P₁₃. In the present embodiment, partitionsP_(1j), P_(2j) may be members of an application 106, 107 thatcommunicate through the interconnect 103 using their respective endpointservices 110, 111.

For example, a first partition P₁₁ on a first platform P_(fm1) has anoperating system image that executes App1 106; this partition P₁₁ is amember of App1 106. Endpoint 110 services available to App1 106 mayeffectively isolate communications from App2 107, allowing the firstpartition P₁₁ to target the endpoint 110 services of App1 106 residingon a second partition P₁₃ found on a second platform P_(fm3).

In some cases, the interconnect 103 utilizes a networking connectiontechnology for communication requirements beyond the physical server. Insuch cases, endpoints 110, 111 may require communication over a network108, which may use Ethernet and/or other networking technologies.

As an example, App1 106 contains partitions that communicate as adjacentpartitions P₁₁, P₁₂. The data transfer for these communications will bememory, as opposed to wire. Communications between co-located partitionsP₁₁, P₁₃ may implement a low-latency, high capacity medium such asInfiniBand. Partitions P₁₃ and P_(13′) communicating over a wider area,between facilities for example, will communicate through a network 108,such as a local area network (LAN) or, in some embodiments, a wide areanetwork (WAN).

In some embodiments, specific partitions P_(1X′) are configured toprovide high availability. That is, a partition P_(13′) may be aredundant copy of its counterpart P₁₃ for redundancy.

FIG. 1A illustrates fault trees relating to each application in theexemplary embodiment of FIG. 1.

In FIG. 1A, each application 106, 107 is mapped to the physical topologyrequired to operate each of the applications. For example, App2 107 isfunctionally dependent upon on either P_(fm1) or P_(fm4) beingfunctional. In some embodiments, application availability is managedthrough a fault tree similar to that of FIG. 1A for high-availability.The common infrastructure of FIG. 1 extends availability of components,such as applications 106, 107 across multiple geographic areas. FIG. 1and FIG. 1A brings components into a single infrastructure, or fabric,for redundancy, high-availability, and ubiquity.

A Fabric Operating System

FIG. 2 illustrates a prior art application execution environment withexamples of services available in an integrated operating system stack.

In FIG. 2, an application execution environment 200 contains severaltypes of services that may be available in an integrated operatingsystem stack. Examples of operating systems 202 that are an integratedoperating system include Linux®, Windows®, and Unix®.

An integrated operating system 202 provides a set of applicationprogramming interfaces to low-level services needed to execute anapplication itself; examples of these low-level services may includememory management, CPU management, task or thread management, and so on.An application programming interface (API) is code, software, firmware,or other module of a computer, which specifies how various programs,software, firmware, and other aspects of computing devices, shouldinteract.

The integrated operating system 202 also provides APIs to a set ofhigh-level services 204, such as a data management service 204E, using,for example, a SQL API. Further examples may include a message service204A using, for example, the IBM® WebSphere® Message Queue API; anauthentication service 204I using, for example, the Kerberos API: and afile and storage management service 204C using, for example, the POSIX®API.

Depending on the operating system deployed onto a platform, theservices, and the manner in which they execute, may vary. Management ofthe integrated operating system is often accomplished by managementtools also integrated into the operating system itself. Depending uponthe embodiment, various integrated operating systems may be used,thereby resulting in a heterogeneous environment.

FIG. 3 illustrates a fabric operating system approach to providingservices to an application in an exemplary embodiment of the commoninfrastructure.

In FIG. 3, a partitioning hypervisor 310 that enables the fabricinterconnect 304 and one or more secure, isolated virtual platforms, orpartitions 302 on which the application execution environments 302A,302B and also on which the fabric operating system services 306 execute.A partition 302 provides a commissioned operating system 312A, 312B witha set of hardware resources allocated from the physical platform.

In certain embodiments, when creating, or commissioning, a new partition302, an administrator may choose the software tools to manage thevirtual platform's hardware. Non-limiting example may be a simplehardware adaptation layer, a microkernel operating system, or a fullintegrated operating system environment.

The services 306 related to a first application execution environment302A may execute independently from services 306 related to a secondapplication execution environment 302B. Moreover, each of theseapplication execution environments 302A, 302B may execute independentlyfrom each of the fabric operating system's services 306.

Depending upon the embodiment, a partition's 302 operating system 312A,312B may range from a simple hardware adaptation layer to asophisticated integrated operating system, such as the exampleintegrated operating system 202 illustrated in FIG. 2. The particularoperating system for a partition in an exemplary embodiment may be basedon the needs of one or more services 204A-N that are hosted by theparticular partition 302.

Embodiments of the fabric operating system provide common fabricoperating system services 306 that may be used by all applicationexecution environments 302A, 302B. Thus, depending upon the embodiment,one or more particular partitions' 302 operating systems 312A may bescaled back to implement only a subset of the services that are requiredto execute an application, thereby relying on the fabric operatingsystem's services 306 to supply higher-level services unrelated to theapplication's execution.

The interconnect 304 provides interconnectivity among the applicationexecution environments 302A, 302B and the fabric operating systemservices 306 provided for their use from within the fabric 300. In someembodiments, the fabric interconnect 304 may be a high-speed,low-latency interconnection protocol and/or hardware, which may employtechnologies such as InfiniBand or other high-speed, low-latencyconnectivity technology.

The fabric operating system services 306, which execute independently ofthe application execution environments 302A, 302B and executeindependently of each other to provide services in support of theapplications hosted in the partitions 302 of the fabric 300.

Depending upon the embodiment, and based on the needs of the servicebeing hosted in the partition 302, the partition's 302 operating system312A execution environment 302A may range from a simple hardwareadaptation layer to an integrated operating system.

The fabric manager 308 executes as a part of the fabric environment 300,but independently of the application execution environments 302A, 302Band independently of the fabric operating system services 306.

The interconnect 304 may provide interconnectivity between components,perform various security functions, and perform one or more managementduties for the fabric 300. The interconnect is managed by the fabricmanager 308.

The fabric operating system is different from any of the integratedoperating systems 312A, 312B because the application executionenvironment 302A, 302B and the operating system services 312A, 312Bexecute independently on their own virtual platforms, i.e., partitions302.

The fabric operating system is distinct from each distributed operatingsystem 312 of the fabric 300. Each virtual platform 302 in the fabric300 hosts its own homogeneous operating system 312A, 312B. Thedistributed fabric operating system is a heterogeneous environment thatis the sum of constituent parts, i.e., the operating systems 312A, 312B.

The fabric operating system's constituent operating systems 312 may eachbe hosted on independent physical and/or virtual platforms 302. However,the fabric operating system projects a homogenous integrated operatingsystem view to each of the applications that are hosted within thefabric 300 environment, thereby obscuring and/or hiding the distributednature of the underlying services supplied from the applications and/orservices 306 in the fabric 300.

An embodiment of a fabric operating system comprises the constituentheterogeneous operating systems residing on partitions, which in somecases include one or more integrated operating systems. By contrast, innetwork operating systems, all participating devices in the networkenvironment, or nodes, are assumed to be homogeneous. Embodiments of afabric operating system are not constrained by homogeneity. The nodes ina network operating system focus on a means for allowing the nodes tocommunicate. In some embodiments, the fabric operating system mayimplement an interconnect as just one in a plurality of possibleservices.

A network operating system focuses on providing a service such as a fileserver service, for example, a client-server software application.Embodiments of a fabric operating system may include the softwareapplication execution environments in addition to the service providerenvironments. That is, a fabric operating system may not follow aclient-server model. In certain embodiments, the fabric operating systemmay separate between the application execution environments and theservice environments, but may not include the management of the commoninfrastructure environment provided by the fabric manager, nor thesecurity or isolation provided by the interconnect and the hypervisor.

In some embodiments, the fabric operating system uses the native APIsprovided by the services of the constituent operating system andcomponent applications. A fabric operating system does not enforce asingle set of APIs between the service providers and the serviceconsumers and is therefore more robust than an enterprise service bus.

The heterogeneous operating system model of the fabric operating systemuses the interconnect to utilize the services residing in each of theseparate heterogeneous execution environments, such as partitions and/orvirtual machine. Thus, services may traverse partitions, from a firstoperating system image to another, as though local to the firstoperating system image. That is, in some embodiments, the set of allservices across the partitions may present the same behaviors of aconstituent operating system.

Operating System Images, Blueprints, and Commissioning

In some embodiments, a customer may select from one or more possibleoperating systems to implement on the partitions. Depending upon theembodiment, operating system images may provide choice of preconfiguredoperating system blueprints that may be quickly deployed, easily cloned,and maintained.

In embodiments utilizing blueprints, the hypervisor may createpartitions to populate them quickly with blueprinted images. That is,partitions may be generated using a blueprint. High levels of automationfor commissioning operating systems and managing runtime operationenhances resilience and availability and also reduces operational costs.

Referring to FIG. 1A, some embodiments may implement automationtechniques that may determine one or more platforms on which thesepartition images may be commissioned, thereby providing redundancy andfault tolerance. Further embodiments may utilize these automationtechniques to determine the most efficient and/or effective partitions,which should receive a commissioned partition blueprint, operatingsystem image, and/or application.

For example, in an exemplary embodiment illustrated in FIG. 1A, App1 106is initially executed within four execution environments: the executionenvironments of member partitions P₁₁, P₁₂ residing on a first platformP_(fm1), and the execution environments of member partitions P₁₃, P₁₄residing on a third platform P_(fm3). In this exemplary embodiment, thecommon infrastructure may automatically determine that a second platformP_(fm2) and a fourth platform P_(fm4) are effective platforms on whichto commission redundant member partitions P_(11′), P_(12′), P_(13′),P_(14′) of App1 106.

FIG. 4 illustrates the various blueprints that may be commissioned intopartitions of the common infrastructure.

A gold image 401 may be a blueprint that is provided by the fabricadministrator to the customer to implement on one or more partitions.The gold image is a type of blueprint having a standardized operatingsystem. In some embodiments, for example, the gold image 401 may be apreconfigured Microsoft Windows® or Linux distribution.

A data storage and/or data analytics blueprint, or data blueprint 402,may be a preconfigured operating system having a file management andanalytics module. For example, a data blueprint 402 may be a Linux goldimage preconfigured with an instance of a Hadoop distributed filesystem.

Optionally, a customer may provide operating system images to theinfrastructure administrator as a customer-supplied blueprint 403. Thesemay be blue prints having blank gold images 301, which are thenconfigured to support the customer's selections, thereby resulting inthe customer-supplied blueprint 303.

FIG. 5 illustrates the features and process of commissioning operatingsystems, thereby commissioning into the infrastructure one or moreservices that reside on the blueprints.

In S401, one or more blueprints 301, 303 are commissioned into thecommon infrastructure. In FIG. 4, a first blueprint may be a gold image301 executing a customer supplied application 310, and acustomer-supplied blueprint 303 hosting a customer supplied operatingsystem image 312.

In S402, the commissioning process may generate one or more copies, orclones, of the gold image 301. During this cloning, in S402, the one ormore gold images are propagated onto corresponding partition images Ax,Ay.

In S404, the hypervisor partitions one or more platforms P_(fm1) intoone or more partitions P₁₁ that will execute the partition images Ax,Ay. In some embodiments, a platform P_(fm2) may host one or moreredundant partitions P_(11′).

In S405, the commissioning process may generate clones of thecustomer-supplied image 303. During this cloning, in S405, the one ormore customer-supplied images are propagated onto correspondingpartition images Xx, Xy.

In S406, the hypervisor partitions one or more platforms P_(fm1) intoone or more partitions P₂₁, which will be receiving the partition imagesXx, Xy. In some embodiments, a platform P_(fm2) host one or moreredundant partitions P_(21′).

Some embodiments may implement automation to remove administrativeerror, and improve reliability and consistency of an application orother aspect of the infrastructure, thus enhancing mission-criticalapplications.

For example, in some embodiments, automation may enable one or moreblueprints, each having subcomponents of a whole application, to beautomatically commissioned onto partitions, thereby relieving anadministrator of the error-prone task of commissioning the componentsone at a time.

As a further example, some embodiments may automatically determine theproper physical platforms for these subcomponents of an application tocommission onto, thus establishing redundancy and improving applicationavailability.

Further embodiments may automatically commission one or more images assubcomponents of a whole application.

Interconnect Fabric

Depending upon the embodiment an interconnect fabric may comprise somecombination of software, hardware, hardware media, and/or firmware. Theinterconnect may interlink one or more platforms and the partitionswithin them. The interconnect may make the connection technologyimplemented invisible to applications and to the operating systems inthe partitions, thereby facilitating higher-level interface applicationsand programming that expect one type of technology, but allowing forlower-lever technologies to operate independently. One non-limitingexample may be a case where a higher-level socket-based programmingeffort utilizes Ethernet networking protocols, however connectivity maystill operate using InfiniBand, without having to change the applicationto support InfiniBand.

FIG. 6 illustrates an embodiment of the interconnect fabric and thevarious aspects.

The interconnect fabric 600 facilitates communications between thecomponents of the common infrastructure. Depending upon the embodiment,the interconnect fabric 600 comprises any permutation of three aspects:one or more physical fabrics PF1, one or more logical fabrics LF1, LF2,and one or more virtual fabrics VF1, VF2, VF3. Depending upon theembodiment, there may be any permutation of three platforms: a physicalplatform P601, P602, P603, a logical platform L601, L602, L603, and avirtual platform (also called a “partition”) V₁₁, V₂₁, V₂₂, V₃₁.

An exemplary embodiment of the interconnect fabric 600 comprises threephysical platforms P601, P602, P603 each of which host a logicalplatform L601, L602, L603. Each of the logical platforms may host one ormore virtual platforms, or partitions V₁₁, V₂₁, V₂₂, V₃₁.

A physical fabric PF1 may transport data and messages between physicalplatforms P201, P202, P203 of the common infrastructure. Depending uponthe embodiment, the physical fabric PF1 may comprise a collection of oneor more physically isolated segments, one or more switches, one or moreattachment ports, and the one or more platforms.

An isolated segment comprises a transport medium that varies dependingupon the embodiment. Non-limiting examples of transport mediums for anisolated segment include: copper wire, optical cable, and/or a memorybus.

Embodiments may vary based on the physical interconnectivityrequirements, such as geography, redundancy, and bandwidth requirements.For example, in embodiments where each partition (“virtual platform”)resides on the same physical platform there is no need for attachmentports or wiring since all of the partitions are adjacent partitions.Other embodiments may require the physical fabric to span geographicdistances using suitable technologies, e.g., LAN or WAN technologies.

In some embodiments data and messages may be exchanged between physicalsegments via an optional gateway or router device. In some embodiments,a data center hosting one or more common infrastructures may containmore than one physical fabric.

A logical fabric LF1, LF2 may provide a trusted communications pathbetween sets of platforms or partitions. The logical fabric LF1, L2divides the physical fabric PF1 into logical chunks. For example, afirst logical fabric LF1 and a second logical fabric LF2 logicallydivides the physical fabric.

Each logical fabric LF1, LF2 provides a trust anchor for the set ofplatforms or partitions, which are needed to communicate in someembodiments. Embodiments of the common infrastructure interconnect mayhave a physical fabric PF1 utilizing at least one logical fabric LF1,LF2 that enables the trusted communication mechanisms for the logicalplatforms L201, L202, L203 residing on the interconnect fabric 600.

A virtual fabric VF1, VF2, VF3 may reside within a logical fabric LF1,LF2 as a virtualized network. For example, in some embodiments, thevirtual fabric is in the form of a virtual local access network (VLAN).A logical fabric LF1, LF2 may have one or more virtual fabrics VF1, VF2,VF3 within it. For example, a first logical fabric LF1 may host twological fabrics VF1, VF3.

A physical platform P201, P202. P203, is a physical computing device. Insome embodiments it is a server that slides into a server rack; however,it should be appreciated that any computing device capable of meetingthe requirements of the physical platform will suffice. In someembodiments, the physical platform P201, P202, P203 connects to one ormore physical fabrics PF1 with physical cables, such as InfiniBand orEthernet cables.

In some embodiments, the physical platform P201, P202, P203 includes aninterface card and the related software, such as a Integrated Dell®Remote Access Controller (iDRAC) interface card; and the physicalplatform may include BIOS software.

A hypervisor may reside between a physical platform P201 and a logicalplatform L201 layer, thereby creating the logical platform from thephysical components of the physical server.

A logical platform L202 is a set of resources that the hypervisorallocates to the partitions V₂₁, V₂₂ it creates and/or manages on aphysical platform P202, e.g., memory, cores, core performance registers,NIC ports, HCA virtual functions, virtual HBAs, and so on. Dependingupon the embodiment, there are two forms of logical platform L201, L202,L203 operation and characteristics. In some embodiments, a logicalplatform may be a partitionable enterprise partition platform (“PEPP”),and in some embodiments a logical platform may be a non-partitionableenterprise partition platform (“NEPP”).

A PEPP is a logical platform L202 generated by a hypervisor thatgenerated one or more partitions V₂₁, V₂₂ that are intended to utilizeresources allocated from the physical platform P202. In someembodiments, the hypervisor might only expose a subset of a physicalplatform's P202 capabilities to the logical platform L202.

A NEPP is a logical platform L203 that includes all of the hardwarecomponents of the physical platform P203 and an agent module thatcontains credentials that allows the physical platform P203 hosting theNEPP logical platform L203, to join the logical fabric LF2 for logicalplatforms to communicate L202, L203.

A virtual platform V₂₁, V₂₂ is the collection allocated resources thatresult in an execution environment, or chassis, created by thehypervisor for a partition. A virtual platform comprises a subset of thelogical platform's L202 resources that were allocated from the physicalplatform P202 by the hypervisor and assigned to a virtual platform V₂₁.

In some embodiments, each virtual platform's V₂₁, V₂₂ componentry isunique. That is, in such embodiments, the hypervisor will notdual-assign underlying components. In other embodiments, however, thehypervisor may dual-assign components and capabilities, such assituations requiring dual-mapped memory for shared buffers betweenpartitions. In some embodiments, the hypervisor may even automaticallydetect such requirements.

The services in dialog over the interconnect may be hosted in differentpartitions or in the same partition. Depending upon the embodiment,there may be two types of infrastructure connections: memoryconnections, and wire connections. Memory connections may beinter-partition or intra-partition communication that may remain withina physical platform.

Wire connections may be connections occurring over an isolated segment,e.g., a copper wire, using a related protocol, e.g., Ethernet orInfiniBand. Applications may transmit and receive information throughthese wire connections using a common set of APIs. The actualtransmission media protocols used to control transmission areautonomically selected by the embedded intelligence of the interconnectfabric. Embodiments of an interconnect may provide communication APIsthat are agnostic to the underlying transports. In such embodiments ofthe interconnect, the one interconnect may support all transportprotocols.

In the exemplary embodiment, a first partition V₁₁ is capable ofcommunicating with a second partition V₂₁ over a first logical fabricLF1 and a first virtual fabric VF1.

The second partition V₂₁ may communicate with a third partition V₂₂ anda fourth partition V₃₁, over a third virtual fabric VF3. Communicationbetween the second partition V₂₁ and the third partition V₂₂ requireseach of the partitions V₂₁, V₂₂ to share the trust anchors of the firstand second logical fabrics LF1, LF2 with the third virtual fabric VF3because the third virtual fabric VF3 is needed to span the gap betweenthe logical fabrics LF1, LF2.

The third partition V₂₂ may communicate with the fourth partition V₃₁using the second logical fabric LF2 and the third virtual fabric VF3.

Interconnect communications may be of two types: wire connections andmemory connections. Wire connections are inter-server communicationsrequiring some use of network transmission protocols, e.g., internetprotocol (IP) or InfiniBand (IB) connections. In embodiments requiringwire connections applications may transmit and receive informationthrough wire connections using a common set of APIs.

In some embodiments, the intelligence governing interconnect fabriccommunications may autonomically select the actual transmission mediaprotocols used to during transmissions.

Fabric Manager

A fabric manager may be a permutation of software and/or hardwarecomponents that may manage the plurality of functions and the variousaspects of an exemplary embodiment of a common infrastructure.

FIG. 7 is a common infrastructure architecture showing various types ofmanagers in a datacenter and their management domains.

In some embodiments of the common infrastructure, there is a fabricmanagement platform 702 housing a fabric manager 703 that governs theresources and communications of the fabric 701 and the components of thecommon infrastructure.

In some embodiments, a fabric manager 703 may govern partitioning by ahypervisor and manage partition execution environments.

Below the dashed-line, in FIG. 7, is a fabric 701, including thephysical fabric 704, the logical fabric 705, and the fabric manager 703.Various components expose services S1 . . . Sn that may be invoked byvarious services and/or applications.

The logical fabric 705 may comprise the hypervisor module that managesthe partitions 706, the partition interconnections 707, e.g., storageand communications, and the partition images and blueprints 708. Theyphysical fabric 704 comprising the platforms 716 and the physicalinterconnect 717.

The fabric manager 703 is responsible for the management of thecomponents below the dashed line, within the fabric 701. This isachieved by consuming services S1 . . . Sn that are exposed at thephysical 704 and partitioning layers 705.

Above the dashed-line is one or more of the customer's executingsoftware 709 environments. Depending upon the embodiment, variousmanagement tools 709, 710, 711, 712 may be deployed with blueprints 708.Four non-limiting examples are shown in the exemplary of FIG. 7. In someembodiments, management tools may manage at the fabric level and notabove, e.g., power control tools.

One example of a management tool is an Enterprise Management Framework709, which consumes information through agents and APIs that are exposedby hardware of the platform, and operating system 713, middleware 714,and/or applications 715 of a partition image. This information may beused to monitor the platform, operating system, middleware andapplications, providing service management information capabilities,such as capacity management, asset management, incident management andothers.

Another example of a management tool utilized by embodiments of thefabric manager may be a lifecycle manager 710. A lifecycle manager mayautomate the lifecycle of images 708 within partitions 706, by consumingthe fabric manager's services S1-S5. That is, in some embodiments, thefabric manager 703 may commission and/or decommission an image 708 of apartition 706. The lifecycle manager 710 may interact with the fabricmanager's services S1-S5 to facilitate automation of commissioning anddecommissioning.

Depending upon the embodiment, the fabric manager may provide for anumber of functions. In some embodiments, a fabric manager may automateprovisioning of new secure partitions, and in some cases, further allowa customer to control the process. In some embodiments, a fabric managermay switch between a plurality of operating system and/or applicationenvironments, resize them, and/or retarget them to a differentpartition. In some embodiments, a fabric manager may monitor and/ormanage components of the fabric through a single user interface, or“single pane of glass.” In some embodiments, a fabric manager mayperform centralized auditing of various user actions; in suchembodiments, the fabric manager may perform logging. In still furtherembodiments, a fabric manager may further perform call home services.

Depending upon the embodiments, the single pane of glass interfacecontrolling fabric manager, and may facilitate platform management,partition management, component diagnostics, infrastructure automation,auditing and/or logging, providing alerts for events and remediation,identity and access management, license management, and provisioning andconfiguration of partitions. The user interface may further providecontrols of partitions, for example, the interface may allowadministrators and/or customers to add a platform, commissionpartitions, decommission partitions, resize a commissioned partition,and perform call home services. The interface may facilitate addingoperating system images and blueprints.

In embodiments where the fabric manager may automate commissioning, anadministrator may instantiate a partition lifecycle limit on thepartition. The partition may be created out using a blueprint and goldimage, or it could be created out of a customer-supplied image orblueprint.

Moreover, some embodiments in which the fabric manager facilitatescommissioning, an initial discovery may be performed by the fabricmanager to make sure that the target platform receiving the partitionhas adequate resources available for commissioning the partition image.

Such a determination may check whether the target platform has adequatenetwork connections, disks, access valid blueprints, access to validoperating system images, sufficient computing resources such assufficient cores and memory to use.

Depending upon the embodiment, an administrator may select a validblueprint, or the fabric manager may automatically select the validblueprint. For example, if the administrator or operator wants tocommission the SLES 11 SP3 partition image it could select the blueprintas SLES 11 SP3.

Some embodiments of the interface implement a unified management GUIhaving role-based controls allowing a plurality of individuals toadminister the various aspects of the common infrastructure system.Role-based controls may facilitate multiple people in different rolesfor administering different pieces of the common infrastructure system.

Some embodiments of a common infrastructure can authenticate users usingexisting credentials. Credentials may be managed by any commonly usedcredential management service, such as lightweight directory accessprotocol (“LDAP”), a native user directory, or Kerberos.

In some embodiments, the fabric manager may set up a security partitionthat facilitates user authentication. In some cases, one or moreservices have access to the various internal LANs, but not a broaderenterprise LAN in which an authentication directory may reside. Asecurity partition facilitates an authentication source for a commoninfrastructure service to authenticate itself, thus effectively reachingthe enterprise credentials by proxy.

In such embodiments, the fabric manager may authenticate using theselected credential management service. The security partitionrepresents a single point of authentication for the fabric manager toauthenticate a user or service so that anyone on any infrastructureserver can use the security partition for authentication.

In some embodiments, this fabric management platform is the source oftime for the platform components, such as the hypervisor of eachplatform. However, the fabric management platform itself can be thesource of time, or alternatively it can be connected to another timesource. For some partition images, a customer of the commoninfrastructure may select the fabric management platform as the timeserver, or some other source. Service partitions may all use the fabricmanagement platform as the time server.

Some embodiments of the fabric manager may monitor a health status ofany of the fabric manager, the common infrastructure, a particularpartition, and/or a particular platform. In such embodiments the fabricmanager may monitor a server health for resource usage such CPU usage,memory usage, swap usage, and disk usage.

Some embodiments of the fabric manager monitor may display platformstatus information on a user interface. This status information relatedto the platform may relate to a call home event, in which aninfrastructure threatening event requires the fabric manager to send anotification of the event to an administrator or vendor. Such statusinformation may also include information concerning power status,partition status, and/or hypervisor status.

Some embodiments of a fabric manager may disable a partition. Disablingis required to facilitate resizing a partition. Resizing is an optionalfabric manager feature allowing the fabric manager to instructhypervisor to enable, disable, or amend allocated resources of, apartition when more than one partition resides on a platform. In otherwords, disabling a partition may release one or more platform resourcesso that those resources may be used by another partition.

In embodiments of the fabric manager that may decommission a partition,the fabric manager may delete or completely destroy a partition from theplatform to free the platform resources for one or more new commissionedpartitions.

In embodiments of the fabric manager that may add a new platform, thefabric manager must incorporate a new physical platform added to theinfrastructure. That is adding a platform may be the initialinstallation of a platform. In some cases, a non-partitionableenterprise partition platform (NEPP) is added, which is platform withouta hypervisor.

A fabric manager may be connected to the platforms and partitionsthrough a dedicated fabric manager LAN network.

Embodiments of the fabric manager that manage blueprints and/or imagesmay add a blueprint, handle uploaded blueprints, delete blueprints,and/or authorize new gold images.

In some circumstances, a customer may need a new blueprint and/or a newimage to be added, and in some the existing images could be deletedbefore adding the new image. Embodiments of the fabric manager may allowa customer to upload one or more new images. This customer may selectuploading the new image to multiple platforms. There are similarembodiments of the fabric manager to facilitate managing the blueprintsin the common infrastructure.

Some embodiments of the fabric manager may monitor infrastructureevents. Events may be general events or call home events. General eventsmay be audit or system-related events generated by the system regardingthe general health of the infrastructure, the components, andapplications. Audit events are associated with user actions, such aswhen a user logs in or out, performs some operation like powering on adevice, or instantiates commissioning of one or more partition images.

Call home events may be a set of events generated from the platform andevents relating to the platform. For example, hardware failures of theCPU processor and/or failure of the hypervisor. In some embodiments, thefabric manager may pull events from the platforms and/or hypervisors atregular intervals. In further embodiments, the fabric manager mayperform some filtering and then send some of these critical call homeevents to the manufacture and/or vendor.

In some embodiments, call home events may be published to an one or morecommon infrastructure management tools or systems, which are outside ofthe fabric. For example, an event may be published to an external agentor application to inform a third-party servicer, and/or other concernedparties or software, of changes to the common infrastructure, such as aresource being added or deleted.

Data Storage

Some embodiments of a common infrastructure include data storage anddata analytics capabilities. Such embodiments comprise one or moredistributed file systems, e.g., Hadoop, for expandable data storageand/or analytics efforts. An exemplary fabric may commission as manypartitions containing distributed file systems as needed, therebysupporting the analytics efforts performed by applications. In someembodiments, commissioning and decommissioning such data storagepartitions may be handled by a fabric manager.

Data Storage in a Data Foundation

In a common infrastructure paradigm data may be stored on one or morephysical platforms, e.g. physical servers, capable of storing data. Insome cases, these platforms may be formed grouped into one or moreclusters. In some embodiments of data storage, data retrieval may occurfrom, or by, one or more commodity components.

Storage and execution of data in a common infrastructure may be inmanner that is agnostic to the infrastructure's commodity components,e.g., applications, data, databases, and/or analytics logic. That is,the data may utilized by each of the individual operating systems and/ordatabases such that data may reside within the common infrastructurewherever the most effective mix of reliability, security, andconvenience may be found.

A common infrastructure embodiment may store data in a data foundationcomprising one or more physical platforms for storing and/or retrievingdata and implementing various data analytics techniques. The datafoundation may facilitate data analytics and/or transactionalapplications that requires the use of one or more databases andanalytical engines, such as an application for online reservations orbooking. Such applications may utilize heterogeneous sub-componentsresiding on the common infrastructure.

The data foundation may facilitate analytics tools that drive dataprocessing of the stored data. These analytics tools are drawn from theinfrastructure's heterogeneous components, and may draw data storedwithin the infrastructure's heterogeneous components. The data is drawnfrom these various components using tailored metadata perspectives thatmitigate well-known complications for accessing data across theseheterogeneous systems.

In some embodiments, these metadata perspectives are stored in ametadata perspective store, which may be a non-transitorymachine-readable storage medium. Metadata perspectives control executionof a metadata processor. The metadata perspectives processor mayimplement a metadata perspective associated with a particular databasemodel, to structure according to the particular database model.

Data stored in the common infrastructure may be available for ubiquitousor near-ubiquitous accessibility, both geographically andtechnologically.

In some embodiments, the common infrastructure may store data in adatabase requiring the data to conform to a well-known structuralrepresentational model. Examples might include relational databases,object-oriented databases, and network databases. In such embodiments,the common infrastructure migrates data into a common data store storageparadigm, discussed below.

A first data foundation functionality relocates traditionalclient-server databases, such as Oracle® and Microsoft SQL Server®, ontoone or more multi-partition platforms. The partitions will beco-resident with a trusted common infrastructure environment, therebyfacilitating quick application database to external database withoutapplication changes by leveraging features of the common infrastructure,such as the interconnect fabric.

Another data foundation functionality is implementing a distributed filesystem. The distributed file system is incorporated into one or morecommon infrastructure platforms to facilitate deployment of newapplications and/or extend existing applications.

In some embodiments, this may data foundation functionality may includeone or more native application programming interfaces (API). In otherembodiments, the functionality may be drawn from a diverse selection ofopen data analytics tools and distributed file system software.Implementing this data foundation functionality combines data residingon the common infrastructure with other data sources, into customizable,dynamic, business-relevant decision support solutions.

Another data foundation functionality facilitates ubiquitous data accessby replicating data to one or more platforms within the commoninfrastructure. Some embodiments implement a databus that extracts newand updated data from the common infrastructure and other data sources.The databus transforms the data using metadata techniques to meetrepresentational demands of one or more common infrastructurecomponents, and may then automatically apply one or more updates to thecommon infrastructure and/or other data sources. Some embodiments mayimplement a databus to agnostically make data available to the variousapplications residing in the common infrastructure, performing analysis,monitoring, and action.

Common Data Store and Metadata Perspectives

A common infrastructure embodiment may implement a common data storethat may store data in a format free of the representational constraintsimposed upon the system by well-known databases. Data stored in thiscommon data store may be used by a component in the infrastructure,without requiring replication from one database to another.

A common data store may store data into a form that is free ofrepresentational constraints, such as those required by relationaldatabases. In this form, the system may implement data wherever the datais required without necessitating replication. Embodiments utilizing acommon data store may use metadata and software generation techniques tocreate tailored “metadata goggles” allowing components to automaticallyview data in the expected former representational forms.

FIG. 8A illustrates a prior art data storage paradigm where dataconforms to expected structural requirements of a database.

In FIG. 8A, three applications 802 a, 804 a, 806 a store and retrievedata in a prior art data storage paradigm. An application 802 a storesdata in a particular database 802 d. The application and the databasecommunicate through an expected data model 802 b, which maintains anexpected set of structural rules for the data being stored andretrieved. Thus, data analytics 802 c may not be performed on data usedby another application 804 a since it must be stored in another database804 d in a manner conforming to that database 804 d. Often, data must bereplicated between databases 802 d, 804 d to permit backups and/or toensure operability of the replicated data.

FIG. 8B, illustrates one embodiment of a data foundation common datastore.

In the exemplary embodiment, the data foundation 800 common data storemay comprise a key-value store 812, which stores one or more key-valuepairs 818 in a non-transitory machine-readable storage medium. Akey-value pair 818 comprises a key that is a unique identifier foruniquely identifying an associated datum, or value. A value may beinformation of any type, and is not limited to numerical values. In somecircumstances, a key-value pair 818 may be a triple 820. A triple 820being data composed of, or stored in, a subject-predicate-object format.

The data foundation 800 uses a key-value store 812 as a means ofdeconstructing data to remove the models 802 b, 804 b, 806 b imposed bya database 802 d, 804 d, 806 d, or other data source, originallyreceiving or transmitting the data. The key-value store 812 stores datain a manner that is agonistic to the various databases 802 d, 804 d, 806d, and/or data sources. The data foundation 800 may comprise a metadataperspective processor 808. When data is accessed from the datafoundation 800 by an application 802 a, the metadata perspectiveprocessor 808 may reconstruct the data, which is now stored as key-valuepairs 818, into objects that satisfy the database model 802 b expected.

Using metadata tags 822 stored in a meta store 816, the common datastore 812 may generate one or more metadata perspectives 808 that areeach tailored to the various database models 802 b, 804 b, 806 b thatare storing and querying data into the data foundation 800.

The commodity applications 802 a, 804 a, 806 a interact with one or moredatabases in the infrastructure. The applications 802 a, 804 a, 806 amay store and/or retrieve data from these various databases. Each ofthese databases may implement a different representational structure, ormodel 802 b, 804 b, 806 b defining the manner in which data is organizedwhen the data is stored and/or retrieved by an application 802 b, 804 b,806 b through a particular database.

For example, in the event that a commodity application 802 a is storingnew data in a database, the commodity application 802 a, or othermiddleware, must present that new data to the database in a model 802 bexpected by the database. Such representational conformity within asingle database may hinder usability of the data across database models804 b, 806 b.

A metadata perspective 808 generated by the data foundation 800 allowsthe data to be presented to a database in a model 802 b the databaseexpects, though the underlying data is unchanged. The metadataperspectives 808 allow commodity applications, programs, and devices, toautomatically view data in the representational form they expect.

Example #1, is an example of call home services. In Example #1, there isa power supply failure on the platform. At this point there will be someevents generated on the platform, which are then pulled by the fabricmanager. The fabric manager determines that this is a call home event byreferencing user-generated criteria, and then the fabric managergenerates a call home event. The fabric manager then sends alerts to theappropriate administrators and to the vendor of the platform to takenecessary actions, and also logs the event.

Example #2 is an example of partition commissioning. A user interfacecomprises a platform summary displaying information about a platform,e.g., platform name, a description of the platform, and variousattributes associated with the platform, and whether a platform is aPEPP or a NEPP.

The user interface may display status information from a managementagent stored on the platform, such as the health of the platform. If theplatform is a PEPP, the interface may also display what is the status ofthe hypervisor instance running inside of the PEPP platform. Theinterface may also information about the partitions that are runninginside the platform and the current state of these partitions. In thecase of the NEPP, there is only one partition since there is nohypervisor that may allocate resources for instantiating multiplepartitions inside the platform.

The administrator may begin commission a new partition, or the fabricmanager may automatically do so. Commissioning a partition image socommissioning a partition image involves bringing a partition toproduction. The new partition image is based on a partition blueprinthaving a Microsoft® Windows® gold image.

The administrator could select the target platform, or the fabricmanager may automatically detect that a new partition is needed on thetarget platform. Once begun, some initial discovery determinations areperformed by the fabric manager to make sure the target platform hasadequate resources available for commissioning a partition image. Thecommissioned blueprint is then loaded.

Basic information may be supplied concerning partition location andattributes. The administrator may decide how the partition is to beconnected to the common infrastructure. That is, the administratordecides which network interface card (NIC) ports the hypervisor on theplatform will allocate to the new partition. Next, the administratordecides the partition size and the amount of memory that will beallocated for the partition.

Example #3 is an example of handling outdated partitions. In Example #3,a fabric manager may disable a partition to resize the partitionsrunning on a platform. The hypervisor may then release certain resourcesso that those resources can be used by another partition on theplatform.

When decommissioning an outdated partition, the partition is deleted orcompletely destroyed to free up resources for a next set of commissionedpartitions from the fabric manager.

Example #4 is an example of manage blueprints and images. In Example #4,a customer uploads a new blueprint and a new version of image may beadded, and the existing images could be deleted before adding the newimage. Once uploaded, the user may decide to instantiate an image ontomultiple platforms. The fabric manager then requires the agents of eachof the platforms to install the new image version. A hypervisor may be amanagement agent, or comprise a management agent module, for a PEPPplatform. The fabric manager may install a management agent onto a NEPPplatform.

The foregoing method descriptions and the process flow diagrams areprovided merely as illustrative examples and are not intended to requireor imply that the steps of the various embodiments must be performed inthe order presented. As will be appreciated by one of skill in the artthe steps in the foregoing embodiments may be performed in any order.Words such as “then,” “next,” etc. are not intended to limit the orderof the steps; these words are simply used to guide the reader throughthe description of the methods. Although process flow diagrams maydescribe the operations as a sequential process, many of the operationscan be performed in parallel or concurrently. In addition, the order ofthe operations may be re-arranged. A process may correspond to a method,a function, a procedure, a subroutine, a subprogram, etc. When a processcorresponds to a function, its termination may correspond to a return ofthe function to the calling function or the main function.

The various illustrative logical blocks, modules, circuits, andalgorithm steps described in connection with the embodiments disclosedherein may be implemented as electronic hardware, computer software, orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentinvention.

Embodiments implemented in computer software may be implemented insoftware, firmware, middleware, microcode, hardware descriptionlanguages, or any combination thereof. A code segment ormachine-executable instructions may represent a procedure, a function, asubprogram, a program, a routine, a subroutine, a module, a softwarepackage, a class, or any combination of instructions, data structures,or program statements. A code segment may be coupled to another codesegment or a hardware circuit by passing and/or receiving information,data, arguments, parameters, or memory contents. Information, arguments,parameters, data, etc. may be passed, forwarded, or transmitted via anysuitable means including memory sharing, message passing, token passing,network transmission, etc.

The actual software code or specialized control hardware used toimplement these systems and methods is not limiting of the invention.Thus, the operation and behavior of the systems and methods weredescribed without reference to the specific software code beingunderstood that software and control hardware can be designed toimplement the systems and methods based on the description herein.

When implemented in software, the functions may be stored as one or moreinstructions or code on a non-transitory computer-readable orprocessor-readable storage medium. The steps of a method or algorithmdisclosed herein may be embodied in a processor-executable softwaremodule which may reside on a computer-readable or processor-readablestorage medium. A non-transitory computer-readable or processor-readablemedia includes both computer storage media and tangible storage mediathat facilitate transfer of a computer program from one place toanother. A non-transitory processor-readable storage media may be anyavailable media that may be accessed by a computer. By way of example,and not limitation, such non-transitory processor-readable media maycomprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage,magnetic disk storage or other magnetic storage devices, or any othertangible storage medium that may be used to store desired program codein the form of instructions or data structures and that may be accessedby a computer or processor. Disk and disc, as used herein, includecompact disc (CD), laser disc, optical disc, digital versatile disc(DVD), floppy disk, and blu-ray disc where disks usually reproduce datamagnetically, while discs reproduce data optically with lasers.Combinations of the above should also be included within the scope ofcomputer-readable media. Additionally, the operations of a method oralgorithm may reside as one or any combination or set of codes and/orinstructions on a non-transitory processor-readable medium and/orcomputer-readable medium, which may be incorporated into a computerprogram product.

The preceding description of the disclosed embodiments is provided toenable any person skilled in the art to make or use the presentinvention. Various modifications to these embodiments will be readilyapparent to those skilled in the art, and the generic principles definedherein may be applied to other embodiments without departing from thespirit or scope of the invention. Thus, the present invention is notintended to be limited to the embodiments shown herein but is to beaccorded the widest scope consistent with the following claims and theprinciples and novel features disclosed herein.

While various aspects and embodiments have been disclosed, other aspectsand embodiments are contemplated. The various aspects and embodimentsdisclosed are for purposes of illustration and are not intended to belimiting, with the true scope and spirit being indicated by thefollowing claims.

What is claimed is:
 1. A computer-implemented method for managing a setof computing resources, comprising: determining, by a computer, targetcomputing resources to be configured with a physical platform;determining, by the computer, whether the target computing resourcesincludes a management agent for managing the physical platform; causing,by the computer, a management agent to be installed on the targetcomputing resources if the target computing resources are determined tonot include a management agent, otherwise, not causing a managementagent to be installed on the target computing resources; andinstructing, by the computer, the management agent to add the physicalplatform to the set of computing resources.
 2. The method according toclaim 1, further comprising receiving, by the computer, one or more usercommands from a user interface allowing a user to control the computer.3. The method according to claim 1, further comprising altering, by thecomputer, the computing resources on which the physical platform is tobe configured.
 4. The method according to claim 3, wherein alteringincludes creating a virtual platform on the target computing resourcesprior to instructing the management agent to commission the virtualplatform.
 5. The method according to claim 4, further comprising:receiving, by the computer, a command to decommission the virtualplatform from a portion of the computing resources; and removing, by thecomputer, the decommissioned portion of the computing resources frombeing accessed; and returning the portion of the computing resources toa pool of available computing resources for the physical platform. 6.The method according to claim 5, wherein the obsolete computingresources includes a management agent configured to manage a virtualplatform.
 7. The method according to claim 1, wherein instructing themanagement agent to add the physical platform further includesinstructing the management agent to commission a virtual platform. 8.The method according to claim 7, further comprising: instructing themanagement agent to establish a second virtual platform on second targetcomputing resources; and configuring the computer to communicate withthe virtual platform and second virtual platform via a communicationschannel.
 9. The method according to claim 8, further comprising enablingthe computer to access resources of the target computing resources andsecond target computing resources supporting the virtual platform andsecond virtual platform.
 10. The method according to claim 9, furthercomprising: determining, by the computer, that the virtual platformneeds additional computing resources; and causing, by the computer,additional computing resources to be available to the virtual platformon the second target computing resources in response to determining thatthe virtual platform needs additional computing resources.
 11. Themethod according to claim 1, further comprising: instructing themanagement agent to establish a second physical platform on secondtarget computing resources; and configuring the computer to communicatewith the physical platform and second physical platform via acommunications channel.
 12. The method according to claim 11, furthercomprising enabling the computer to access resources of the targetcomputing resources and second target computing resources supporting thephysical platform and second physical platform.
 13. The method accordingto claim 12, further comprising: determining, by the computer, that thephysical platform needs additional computing resources; and causing, bythe computer, additional computing resources to be available to thephysical platform on the second target computing resources in responseto determining that the physical platform needs additional computingresources.